Characterizing user behavior via intelligent identity analytics

ABSTRACT

Methods, devices, and systems are provided to rapidly detect and prevent cyber-attacks that are enabled by either misuse of identity credentials or weaknesses within the identity credential lifecycle. An Identity Analytics and Intelligence Engine provides an automated process for the collection, exchange, analysis, correlation, and reporting of identity credential lifecycle data. The Identity Analytics and Intelligence Engine may be implemented as a Software as a Service (SaaS) capability. The Identity Analytics and Intelligence Engine applies Semantic Web concepts/technologies and graph databases to automatically capture the identity credential lifecycle data along with the associated data exchanges within one or more Trust Frameworks.

CROSS REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. application Ser. No.14/699,086, filed Apr. 29, 2015, now U.S. Pat. No. 9,679,125, whichclaims the benefit of and priority, under 35 U.S.C. §119(e), to U.S.Provisional Application Ser. No. 61/985,955, filed Apr. 29, 2014,entitled “Characterizing User Behavior Via Intelligent IdentityAnalytics,” the entire disclosures of which are hereby incorporatedherein by reference, in their entirety, for all that they teaches andfor all purposes.

BACKGROUND

Misuse of Information Technology (IT) identity credentials is asignificant enabling factor for cyber-attacks. The resulting costs to abusiness to resolve these attacks can be very high. Some examplebusiness costs may include, but are not limited to, lost revenue,customer restitution, an extensive public relations campaign to repairpublic image (e.g., associated with the business and/or organizationthat suffered the attack, etc.), legal fees, regulatory fines, etc.Organizations are currently making large investments in cyber-attackprotection products—yet the threat likelihood and associated costs withcyber-attacks continue to rise. Some examples of recent cyber-attackswhere identity credentials were a key enabling factor are shown in Table1 below.

Examples of recent cyber attacks where identity credential misuse wasthe key enabling factor were identified in a study outlined in thefollowing table (Source: Verizon and Ponemon Institute, Cost of CyberCrime Studies):

TABLE 1 Number of Records Key Enabling Example Costs Organization Typeof Data Loss Breached Factor to Organizations Premera Personally 11MStolen Identity Under Analysis - Identifiable Credentials could exceedInformation (PII) and $50M Protected Health Information (PHI) AnthemBC/BS PII and PHI 80M Stolen Identity Under Analysis - Credentials couldexceed $100M JP Morgan Customer Personal 75M Stolen Identity Data notInformation Credentials released eBay PII and Credit Card 145M  StolenIdentity Large drop in Credentials revenues University of PII 309K  Stolen $6M for free Maryland Privileged Credit Identity Monitoring for 2Credentials Years Target PII and Credit Card 70M PII Stolen Identity5.3% Revenue 40M Credit Credentials Loss Card Experian PII 200M Imposter Significant Subsidiary Identity Public Relations CredentialsCampaign 42% of all Intellectual Property, Unknown but Insider Threat 65days to Organizations PII, Credit Card, and Considered with ValidResolve other types Very Large Identity $4.2M-$11.6M Credentials inRecovery Costs

Current cyber-attack protection products provide reactive capabilitiesbased on software behavior patterns (or signatures) of viruses andmalware. Each of the organizations in Table 1 (above) had virus/malwareprotection products in-place. However, the organizations were still leftunprotected against identity credential misuse.

The rapid transition by businesses to “Cloud Computing” and the adventof the “Internet of Things” (IoT) will make the problems and risksassociated with identity credential misuse even worse. For example,Cloud Computing and the IoT can make identity credentials more highlydistributed than they are today because most business utilizeon-premises software capabilities for their Identity and AccessManagement functions that are limited to smaller scale networks andenvironments. However, Cloud Computing and the IoT operate over verylarge-scale, highly distributed networks. As a result, it is expectedthat the number of identity credentials in use at any given time willincrease exponentially. This increase in identity credential usage cancause large amounts of data to go ignored due in part to the sheermagnitude of data available.

SUMMARY

It is with respect to the above issues and other problems that theembodiments presented herein were contemplated. In general, embodimentsof the present disclosure provide methods, devices, and systems by whichcyber-attacks may be rapidly detected and/or prevented. In some cases,these cyber-attacks may be enabled by either misuse of identitycredentials and/or weaknesses within the identity credential lifecycle.In one embodiment, an Identity Analytics and Intelligence Engine isprovided for the collection, exchange, analysis, correlation, and/orreporting of identity credential lifecycle data.

In some embodiments, the Identity Analytics and Intelligence Engine mayprovide an automated process implemented as a Software as a Service(SaaS) capability. The Identity Analytics and Intelligence Engine can bebased on a rigorous and formal canonical data model that captures theidentity credential lifecycle data as well as the data interactionswithin a large-scale, distributed Trust Framework. A Trust Framework mayinclude a set of technical, operational, and legal (e.g., regulatory)requirements for identity credential data and data exchanges between oneor more sets of agreeing parties. Among other things, the TrustFramework can establish a secure process with well-defined dataexchanges between the agreeing parties that may be governed by a set ofTrust Policies.

In one embodiment, the Identity Analytics and Intelligence Engine mayapply Semantic Web concepts/technologies and/or graph databases toautomatically capture the identity credential lifecycle data along withthe associated data exchanges within one or more Trust Frameworks.Embodiments of this disclosure provide a Trust Framework baseddescription of the aforementioned automated process. As provided herein,the disclosure describes data elements and associated data exchangesused in the characterization of user behavior via intelligent identityanalytics. The data elements and data exchanges may be analyzed tocreate a Resource Description Framework (RDF) based graph datastructure. By way of example, the RDF based graph data structure may beformally specified in a canonical data model using JavaScript ObjectNotation-Linked Data (JSON-LD) and implemented in a graph database. Dataflow diagrams may be used to describe the data flow processes andinteractions that occur within a Trust Framework. In some embodiments,the Identity Analytics and Intelligence Engine component architecturecoupled with SaaS interfaces can generate an identity credentiallifecycle knowledge base that may be used to derive use, or usage, andbehavior patterns that can rapidly detect identity credential misuse.The intrinsic business and/or cyber-attack value of the IdentityAnalytics and Intelligence Engine to rapidly detect and protect againstidentity credential misuse is also described herein.

Embodiments of the present disclosure provide methods, devices, andsystems by which identity credential misuse can be detected and/orproactively prevented through an automated process that continuouslymonitors and characterizes IT user behaviors.

Identity Analytics and Intelligence can include process of examininglarge amounts of network-based identity credential data to discoverhidden patterns, unknown correlations, and other useful identitycredential related behaviors. For example, Identity Analytics andIntelligence can incorporate “Something you Do” with one or more of thethree other well-known identity credential factors. These identitycredential factors may include “Something you Know” (e.g., a UserIdentification (UserID) and password, etc.), “Something you Have” (e.g.,a secure card or token generator, etc.), and “Something you Are” (e.g.,biometric information such as a fingerprint, iris scan, facialrecognition, etc.). The Identity Analytics and Intelligence Engine mayimplement an automated process that continuously monitors andcharacterizes IT usage, or user behaviors, to rapidly detect and preventidentity credential misuse. In some embodiments, the Identity Analyticsand Intelligence Engine may be embodied as a SaaS solution. This SaaSsolution may be configured to provide a chronology of identitycredential lifecycle events, tracks usage metrics, tracks IT userbehavior patterns, and/or measure a variance between expected IT userbehaviors and unexpected user behaviors, and the like.

As the number of identity credentials in use at any given time increases(e.g., exponentially, etc.) with the transition to Cloud Computing andthe Internet of Things, large numbers of highly related IT useractivities/behaviors associated with identity credentials may occur. Tothe casual observer, these IT user activities/behaviors may appear to bea large number of small, seemingly unrelated activities/behaviorsoccurring in a distributed manner. Prior art solutions do not have anyway to correlate and analyze this large number of highly distributedevents. This lack of correlation and/or analysis leads to a set ofserious challenges that must be addressed. Among other things, thesechallenges can include, but are not limited to, the following points:

Point 1—How to efficiently track and characterize user behavior over alarge-scale network where a very large number of distributed identitycredentials may exist. Of particular concern is the case where internalattacks will not be distinguishable from external attacks.

Point 2—How to rapidly identify inappropriate, unanticipated,non-compliant, and/or illegal IT user behavior. Early detection andautomated process workflows that prevent these kinds of behavior fromoccurring may be essential, and the prior art software behavior/attacksignature products are ineffective against these kinds of threats.

Point 3—How to specify public/private cloud-based Trust Frameworks andenforce them—identity credentials may become a composition of IT userattributes from multiple authoritative sources that can be difficult totrace. Additionally, it may be difficult to prove that the identitycredential attributes are not fraudulent, incorrect, and/orinconsistent. Also, each IT user can have many different distributedidentity credentials that are shared over the large, distributednetwork. In general, the differences/variances between these identitycredentials can appear to very minor, but these differences/variancescan result in major incongruities in authentication and authorizationprocesses and practices.

Point 4—How the identity lifecycle management process needs to changeand adapt to such a large number of highly distributed digital identitycredentials.

Embodiments of the Identity Analytics and Intelligence Engine, asdisclosed herein, can provide solutions to the points raised above.

Capability One—A “Provenance Framework” may provide an identitycredential lifecycle chronology of creation, ownership, data updates,usage, and/or patterns of behaviors. Such a framework can address thetypes of questions shown in the table below:

TABLE 2 Question Importance of Answer Can I determine who Provides theability to detect the use of stolen or an IT user is? improperlyacquired identity credentials as well as detecting if: 1) an imposterhas improperly obtained identity credentials, 2) falsified identitycredential attribute data is being provided, and/or 3) personal identitydata obtained via Social Networking is being improperly used/exploited.Can I determine what Provides the ability to detect insider threats andaccess this IT user the inappropriate use of privileged, needs?administrative access. Can I determine what Provides the ability todetect when an IT User is is normal behavior for performingunanticipated behaviors that could this IT user? indicate improper useof computing resources and/or a potential data loss. Can I determinewhat Provides the ability to specify behavior baselines is businessappropriate and benchmarks for a set of IT Users from which behavior forthis IT formal metrics can be established to measure the user?variance/deviation from normal behaviors.

Capability Two—An automated “Continuous Monitoring” process configuredto rapidly harvest, exchange, analyze, correlate, and report on largeamounts of highly distributed identity credential data. This capabilitymay be used to create a global knowledge base that provides thefollowing types of information through the application of searchqueries, data analytics, and machine learning algorithms.

TABLE 3 Types of Knowledge Available Importance of the KnowledgeCharacterization of the IT User base Establishes a baseline set of ITUsers along with benchmarks for their usage and behavior patterns.Perform segregation of IT User duties Establishes a baseline set ofbusiness analysis appropriate behaviors for each class of IT User alongwith benchmarks for these behaviors. Perform automated IT User accountreviews Establishes a methodology for determining if inappropriateidentity credential data attributes or inappropriate identity credentialdata attribute updates are being made, and it serves as a way to ensurean IT User has not been over or under-privileged for their correspondingjob duties. Detect inappropriate use of administrative Allows for therapid detection of external access threats and especially insiderthreats that can cause large data loss events and/or large andwidespread system outages. Determine “toxic” combinations of accessAllows for the rapid detection of situations authorizations where an ITUser can inadvertently cause harm because authentication andauthorization inconsistencies have been created that can beinadvertently or explicitly exploited. Facilitate and understandmulti-factor Allows for full-spectrum consistency identity credentialaccess analysis to ensure multi-factor identity credentials are actuallyachieving increased Levels of Assurance.

In some embodiments, the continuous monitoring methods and systemsdisclosed herein may be employed to address a number of challengesassociated with the misuse of identity credentials. For example, thecontinuous monitoring methods and systems may address one or more of thechallenges provided in the table below:

TABLE 4 Challenges Solution Method and/or System Stolen IdentityCredentials Continuous monitoring of Usage/Behavior Patterns based onsemantic web derived identity lifecycle relationships Insider Threatswith Valid Identity Continuous monitoring of Usage/Behavior CredentialsMetrics to Rapidly Detect variances from business appropriate behaviorImposter Identity Credentials Provenance Framework to continuouslymonitor identity credential attributes throughout the identity lifecycleWidespread Availability of Personal Identity Proofing that leveragesconsumer Information on the Internet and social information capabilitiesto generate Security media sites Challenge Questions whose answer cannotbe constructed from personal information available on the internet orsocial media sites. Unintended Consequences of Aggregated Logic-BasedAnalysis of Aggregated Authorization Assertions Authorization Tokens andToken Policies for Toxic Combinations Is My Organization MissingImportant Cues Integration of Machine Learning with Data about IdentityCredential Lifecycle Data Analytics over the data collected by multipledisparate products/capabilities to accurately predict the location ofthe “needle in the haystack”

Embodiments include a method, comprising: detecting an identitycredential associated with a user; establishing a baseline use behaviorfor the user and the identity credential; storing the baseline usebehavior in a memory associated with the identity credential; monitoringa use behavior of the identity credential; determining whether adeviation exists between the use behavior and the baseline use behaviorof the identity credential; and providing an output when the deviationis determined to exist, wherein the output is configured to address thedeviation.

Embodiments include a method, comprising: collecting informationassociated with an identity credential associated with a user; andcreating two or more distributed graph databases, wherein each graphdatabase is configured to store identity credential lifecycle dataassociated with the identity credential. Aspects of the above methodinclude receiving a query associated with the identity credentiallifecycle data of the identity credential; arranging, in response toreceiving the query, the identity credential lifecycle data in the twoor more distributed graph databases for the identity credential into atleast one data set having user behavior information; and summarizing theuser behavior information of the at least one data set. Aspects of theabove method include wherein summarizing the user behavior informationof the at least one data set further comprises: applying at least onemachine learning algorithm to the user behavior information of the atleast one data set; and creating, in response to applying the at leastone machine learning algorithm, a use pattern for the identitycredential. Aspects of the above method include creating, in response toapplying the at least one machine learning algorithm, a behavior patternfor the identity credential. Aspects of the above method include storingthe use and behavior pattern for the identity credential in a memoryassociated with the identity credential. Aspects of the above methodinclude receiving a subsequent query associated with the identitycredential lifecycle data of the identity credential; arranging, inresponse to receiving the subsequent query, the identity credentiallifecycle data in the two or more distributed graph databases for theidentity credential into at least another data set having user behaviorinformation; applying at least one machine learning algorithm to theuser behavior information of the at least another data set; creating, inresponse to applying the at least one machine learning algorithm, asubsequent use and behavior pattern for the identity credential; andstoring the use and behavior pattern for the identity credential in amemory associated with the identity credential. Aspects of the abovemethod include wherein arranging the identity credential lifecycle datain the two or more distributed graph databases, further comprises:filtering the user behavior information in the two or more distributedgraph databases for the identity credential. Aspects of the above methodinclude wherein arranging the identity credential lifecycle data in thetwo or more distributed graph databases, further comprises: sorting theuser behavior information in the two or more distributed graph databasesfor the identity credential.

Embodiments include a method, comprising: collecting identity lifecycledata associated with at least one identity credential, wherein theidentity lifecycle data includes at least one use behavior associatedwith the at least one identity credential; determining an anticipateduse behavior based on the collected at least one use behavior associatedwith the at least one identity credential; and measuring a variationbetween the anticipated use behavior and a detected unanticipated usebehavior, wherein the detected unanticipated use behavior includes a usebehavior of the at least one identity credential that is outside athreshold of the anticipated use behavior. Aspects of the above methodinclude wherein the detected unanticipated use behavior includes atleast one of a different subscriber authentication and differentauthorization property for the at least one identity credential than asubscriber authentication and authorization property associated with theanticipated use behavior. Aspects of the above method include whereinthe detected unanticipated use behavior is used to at least one ofenable and authorize additional controlled behaviors in the identitycredential lifecycle data, wherein the additional controlled behaviorsinclude a processing function unavailable to the anticipated usebehavior. Aspects of the above method include wherein the received eventinformation is compared in real-time. Aspects of the above methodinclude wherein notifying the relying party includes rendering an alertimage to a computer display operated by the relying party. Aspects ofthe above method include wherein the identity and intelligence engineautomatically analyzes the canonical data in the graph databases usingone or more machine learning algorithm.

Embodiments include a trust framework situated between a subscriberhaving an identity credential and a relying party that provides one ormore computing resources to the subscriber based on identityauthorization verifications received from the trust framework, the trustframework comprising: an identity and intelligence engine thatautomatically performs the following: (i) maintains a canonical datamodel for identity credential lifecycle data related to the subscriber;(ii) receives event information related to at least one of actions andinactions of the subscriber and catalogs the event information; (iii)compares the received event information with the canonical data model todetermine whether or not the subscriber is acting in conformance withthe canonical data model; and (iv) in the event that the subscriber isdetermined to be acting out of conformance with the canonical datamodel, notifies the relying party thereby enabling the relying party todeny or restrict the subscriber's access to the one or more computingresources. Aspects of the trust framework above include wherein thecanonical data model is maintained with information obtained from aplurality of different data sources. Aspects of the trust frameworkabove include wherein the identity and intelligence engine furthercreates a set of distributed graph databases that represent thecanonical data model. Aspects of the trust framework above includewherein a predetermined deviation between the at least one of actions orinactions and the canonical data model is provided to allow thesubscriber to still be in conformance with the canonical data model evenwhen the at least one of actions or inactions to not exactly match thecanonical data model. Aspects of the trust framework above includewherein the identity and intelligence engine continuously andautomatically updates the canonical data model with the at least one ofactions or inactions when the subscriber is determined to be inconformance with the canonical data model. Aspects of the trustframework above include wherein the identity credential lifecycle dataincludes data related to the creation, ownership, data update, usage,and patterns of behaviors associated with the identity credential.

Embodiments include a non-transitory computer readable medium havinginstructions stored thereon that, when executed by a processor, performany of the methods above.

The phrases “at least one”, “one or more”, and “and/or” are open-endedexpressions that are both conjunctive and disjunctive in operation. Forexample, each of the expressions “at least one of A, B and C”, “at leastone of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B,or C” and “A, B, and/or C” means A alone, B alone, C alone, A and Btogether, A and C together, B and C together, or A, B and C together.When each one of A, B, and C in the above expressions refers to anelement, such as X, Y, and Z, or class of elements, such as X₁-X_(n),Y₁-Y_(m), and Z₁-Z_(o), the phrase is intended to refer to a singleelement selected from X, Y, and Z, a combination of elements selectedfrom the same class (e.g., X₁ and X₂) as well as a combination ofelements selected from two or more classes (e.g., Y₁ and Z_(o)).

The term “a” or “an” entity refers to one or more of that entity. Assuch, the terms “a” (or “an”), “one or more” and “at least one” can beused interchangeably herein. It is also to be noted that the terms“comprising”, “including”, and “having” can be used interchangeably.

“Automatic” and variations thereof, as used herein, refers to anyprocess or operation done without material human input when the processor operation is performed. However, a process or operation can beautomatic, even though performance of the process or operation usesmaterial or immaterial human input, if the input is received beforeperformance of the process or operation. Human input is deemed to bematerial if such input influences how the process or operation will beperformed. Human input that consents to the performance of the processor operation is not deemed to be “material.”

“Computer-readable medium” as used herein refers to any tangible andnon-transient storage and/or transmission medium that participate inproviding instructions to a processor for execution. Such a medium maytake many forms, including but not limited to, non-volatile media,volatile media, and transmission media and includes without limitationrandom access memory (“RAM”), read only memory (“ROM”), and the like.Non-volatile media includes, for example, NVRAM, or magnetic or opticaldisks. Volatile media includes dynamic memory, such as main memory.Common forms of computer-readable media include, for example, a floppydisk (including without limitation a Bernoulli cartridge, ZIP drive, andJAZ drive), a flexible disk, hard disk, magnetic tape or cassettes, orany other magnetic medium, magneto-optical medium, a digital video disk(such as CD-ROM), any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, a RAM, a PROM, and EPROM,a FLASH-EPROM, a solid state medium like a memory card, any other memorychip or cartridge, a carrier wave as described hereinafter, or any othermedium from which a computer can read. A digital file attachment toe-mail or other self-contained information archive or set of archives isconsidered a distribution medium equivalent to a tangible storagemedium. When the computer-readable media is configured as a database, itis to be understood that the database may be any type of database, suchas relational, hierarchical, object-oriented, and/or the like.Accordingly, the disclosure is considered to include a tangible storagemedium or distribution medium and prior art-recognized equivalents andsuccessor media, in which the software implementations of the presentdisclosure are stored. Computer-readable storage medium excludestransient storage media, particularly electrical, magnetic,electromagnetic, optical, magneto-optical signals.

The terms “determine,” “calculate,” and “compute,” and variationsthereof, as used herein, are used interchangeably and include any typeof methodology, process, mathematical operation, or technique.

The term “means” as used herein shall be given its broadest possibleinterpretation in accordance with 35 U.S.C., Section 112, Paragraph 6.Accordingly, a claim incorporating the term “means” shall cover allstructures, materials, or acts set forth herein, and all of theequivalents thereof. Further, the structures, materials or acts and theequivalents thereof shall include all those described in the summary ofthe invention, brief description of the drawings, detailed description,abstract, and claims themselves.

The term “module” as used herein refers to any known or later developedhardware, software, firmware, artificial intelligence, fuzzy logic, orcombination of hardware and software that is capable of performing thefunctionality associated with that element.

It should be understood that every maximum numerical limitation giventhroughout this disclosure is deemed to include each and every lowernumerical limitation as an alternative, as if such lower numericallimitations were expressly written herein. Every minimum numericallimitation given throughout this disclosure is deemed to include eachand every higher numerical limitation as an alternative, as if suchhigher numerical limitations were expressly written herein. Everynumerical range given throughout this disclosure is deemed to includeeach and every narrower numerical range that falls within such broadernumerical range, as if such narrower numerical ranges were all expresslywritten herein.

The preceding is a simplified summary of the disclosure to provide anunderstanding of some aspects of the disclosure. This summary is neitheran extensive nor exhaustive overview of the disclosure and its variousaspects, embodiments, and configurations. It is intended neither toidentify key or critical elements of the disclosure nor to delineate thescope of the disclosure but to present selected concepts of thedisclosure in a simplified form as an introduction to the more detaileddescription presented below. As will be appreciated, other aspects,embodiments, and configurations of the disclosure are possibleutilizing, alone or in combination, one or more of the features setforth above or described in detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are incorporated into and form a part of thespecification to illustrate several examples of the present disclosure.These drawings, together with the description, explain the principles ofthe disclosure. The drawings simply illustrate preferred and alternativeexamples of how the disclosure can be made and used and are not to beconstrued as limiting the disclosure to only the illustrated anddescribed examples. Further features and advantages will become apparentfrom the following, more detailed, description of the various aspects,embodiments, and configurations of the disclosure, as illustrated by thedrawings referenced below.

FIG. 1 is a block diagram of a security architecture and IdentityAnalytics and Intelligence Engine in accordance with embodiments of thepresent disclosure;

FIG. 2 shows a process data flow for register and provisioning a newsubscriber in accordance with embodiments of the present disclosure;

FIG. 3 shows a process data flow for re-provisioning an existingsubscriber in accordance with embodiments of the present disclosure;

FIG. 4 shows a process data flow for a subscriber access request inaccordance with embodiments of the present disclosure;

FIG. 5 shows a process data flow for logging and analyzing subscriberaccess request to a relying party in accordance with embodiments of thepresent disclosure;

FIG. 6 shows a process data flow for continuously logging and analyzingrelying party accesses in accordance with embodiments of the presentdisclosure;

FIG. 7 is a flow or process diagram for normalizing log files inaccordance with embodiments of the present disclosure;

FIG. 8 shows a block diagram of a distributed identity credentiallifecycle data collection process in accordance with embodiments of thepresent disclosure; and

FIG. 9 shows a block diagram of a graph database design model inaccordance with embodiments of the present disclosure; and

FIG. 10 is a flow or process diagram in accordance with embodiments ofthe present disclosure.

DETAILED DESCRIPTION

Before any embodiments of the disclosure are explained in detail, it isto be understood that the disclosure is not limited in its applicationto the details of construction and the arrangement of components setforth in the following description or illustrated in the followingdrawings. The disclosure is capable of other embodiments and of beingpracticed or of being carried out in various ways. Also, it is to beunderstood that the phraseology and terminology used herein is for thepurpose of description and should not be regarded as limiting. The useof “including,” “comprising,” or “having” and variations thereof hereinis meant to encompass the items listed thereafter and equivalentsthereof as well as additional items.

FIG. 1 shows the Identity Analytics and Intelligence Engine 104 in thecontext of a Trust Framework 108 and claims-based security architecture100. The trust framework 108 can establish a secure process withwell-defined data exchanges between the agreeing parties that may begoverned by a set of trust policies. In some embodiments, the securityarchitecture comprises a trust framework 108, a trust frameworksubscriber 136, a relying party 140, and an identity fraud detectioncomponent 132. The various components of the security architecture 100are described in greater detail below.

The Trust Framework 108 may include the set of technical, operational,and legal (or regulatory) requirements that must be satisfied by one ormore Trust Framework Subscribers 136 (e.g., IT Users, etc.), IdentityService Providers (ISP) 120, Relying Parties 140, and theRegistration/Provisioning Authority 112. The Trust Framework 108 mayalso specify the required Level of Assurance that dictates the factorsused in creating the identity credential data attributes andcorresponding identity tokens.

The Trust Framework Subscriber 136 may request network and/or systemaccess from the ISP 120. When a subscriber request is made, the ISP 120can issue Authenticated Identity Tokens. In some embodiments, theauthenticated identity tokens may contain the subscriber's 136 identitycredential data attributes associated with their on-line identity.

The Relying Party 140 may accept Authenticated Identity Tokens from oneor more Trust Framework Subscribers 136. The Relying Party 140 may thenuse the Identity Verification component 124 to verify the AuthenticatedIdentity Token with the ISP 120. As a part of the identity verificationprocess, the ISP 120 may provide the Identity Token AuthorizationAssertions to Relying Party 140 that allows it to determine whatprotected network and/or system resources the holder of theAuthenticated Identity Token can access.

The Identity Fraud Detection component 132 may perform background and/orother checks on the identity data/attributes provided by the Subscriber136 and Authoritative Sources 144. For example, the checks may beperformed when a Subscriber 136 is performing a Registration Requestwith the Trust Framework 108.

Among other things, FIG. 1 provides an operational architecture view ofthe Identity Analytics and Intelligence Engine 104. Additionally oralternatively, FIG. 1 can be described in accordance with one or more ofthe following operational scenarios.

Scenario 1:

The Identity Analytics and Intelligence Engine 104 may be used tosupport the Registration/Provisioning Authority function of the TrustFramework 108. The Registration/Provisioning Authority 112 allows TrustFramework Subscribers 136 to register for network and/or system access.As Trust Framework Subscribers 136 attempt to register within theRegistration/Provisioning Authority 112, the Identity Analytics andIntelligence Engine 104 can be used to search the Authoritative IdentityData Sources 144 to verify that the required identity credentialattribute data exists. Additionally or alternatively, the identitycredential attribute data may be supplied to an Identity Fraud Detectioncapability 132. This Identity Fraud Detection capability 132 may be acloud-based service (e.g., IDology, Socure, etc.). In any event, theIdentity Fraud Detection capability 132 may be configured to performappropriate background checks and/or verify that no negative indicatorsor fraudulent identity data attributes are being used with respect tothe trustworthiness of the subscriber 136.

If the Identity Fraud Detection capability 132 returns validated,positive identity credential data attributes, then the identitycredential data attributes can be automatically provisioned intophysical and/or virtual identity directories. Additionally oralternatively, the metadata for the subscriber's identity credentialdata and corresponding identity token is registered and used for futurereference with respect to seeding the machine learning capability tobegin creating usage and behavior patterns that characterize thesubscriber's 136 system and/or network behavior.

Scenario 2:

Every time a subscriber 136 requests access, for example to at least onesystem resource, the ISP 120 can interface with the Identity Analyticsand Intelligence Engine 104 to log the event and generate the metadataassociated with the Authenticated Identity Token provided by the ISP 120to the subscriber 136.

Scenario 3:

The Identity Analytics and Intelligence Engine 104 can interface withthe Identity Verification Capability 124 which may be used by theRelying Parties 140 via the ISP 120. When the subscriber sends anAuthenticated Identity Token to a Relying Party 140, the Trust Framework108 and Relying Party 140 can use the Identity Analytics andIntelligence Engine 104 to log the reception of the AuthenticatedIdentity Token and the metadata for the event may be generated. In someembodiments, the Relying Party 140 must receive the Identity TokenAuthorization Assertions to complete the authentication andauthorization process. The Identity Verification Capability 124 receivesthe Identity Token Authorization Assertions from the ISP 120 andprovides it to the Relying Party 140. During this exchange, the ISP 120can interface with the Identity Analytics and Intelligence Engine 104 tolog the reception of the authorization assertions, verify the identitytoken authorization assertions against the normal secure usage andbehavior patterns for this identity credential, and even generate therequired metadata. As the Relying Party 140 performs and logs networkand/or system accesses (e.g., service request-responses, etc.) performedon behalf of this trust framework subscriber identity credential, theIdentity Analytics and Intelligence Engine 104 securely scrapes,indexes, and processes best practice network and/or system resource(e.g., application, database, and/or server, etc.) log files maintainedby the Relying Parties 140 to obtain relevant Security Information andEvent Management (SIEM) data. These best practice log files may containidentity credential information that can be used to correlate theauthentication and authorization events with actual network and/orsystem resource usage by the subscriber 136 holding the identitycredentials. As a part of this process flow, the Identity Analytics andIntelligence Engine 104 can also use its data analytics and machinelearning capabilities to establish usage and behavior patterns for thesubscriber identity credentials. As a result, when unanticipatedsubscriber behavior is recognized, the behavior can be automaticallyflagged and/or reported to a cybersecurity situational awareness and/orreporting tool(s) along with any recommended corrective actions.

The following disclosure provides several example use cases for theIdentity Analytics and Intelligence Engine 104 in accordance with theoperational scenarios described above.

Detection of a Subscriber that is an Insider Threat:

The Trust Policies within a Trust Framework 108 may define the securitycontext and boundaries for a subscriber's 136 access. Additionally, theAuthenticated Identity Token and Identity Token Authorization Assertionsin conjunction with the Trust Policies may define which Relying Parties140 a subscriber 136 is allowed to access along with the Relying Party140 resources the subscriber 136 is authorized to access. Furthermore,the combination of the token, assertions, and policies may define thebasis for a subscriber's 136 usage and behavior patterns. A subscriber136 that attempts to operate outside of the subscriber's 136 basis, orbaseline, usage and behavior patterns can be flagged for unanticipatedbehaviors that are determined to deviate from the basis usage andbehavior patterns. For example, the subscriber 136 may be displayingunanticipated usages or behaviors that are typically not associated withthe Authenticated Identity Token, the associated AuthorizationAssertions, and/or the Trust Policies.

Detection of a Subscriber's Stolen Authenticated Identity Token:

This use case is similar to the Insider Threat Use Case described above,but not necessarily be exactly the same. By way of example, a subscriber136 that is an insider threat may obey the rules of the basis usage andbehavior patterns, but the subscriber that is an insider threat may alsoattempt to violate those rules with unanticipated behaviors that canrepresent a security threat. However, an individual using a stolenAuthenticated Identity Token has a very low probability of obeying therules of the basis usage and behavior patterns because the individualwould not necessarily have this information available. As can beappreciated, almost all of the behaviors associated with a stolenAuthenticated Identity Token will be unanticipated and represent asecurity threat.

Detection of a Loss of Trust for a Relying Party (e.g., the RelyingParty has been Compromised):

This use case represents when a Relying Party 140 has been compromisedor has chosen to violate the rules of the Trust Framework 108. Thisviolation may provide Relying Party 140 behaviors that are inconsistentwith the basis usage and behavior patterns established by the TrustPolicies and the subscriber's 136 Authenticated Identity Token andIdentity Token Authorization Assertions. For example, the Relying Party140 behavior may ignore the Identity Token Authorization Assertions andcomplete subscriber request-response access requests to resources thesubscriber 136 should not have access to. This use may representunanticipated behavior by the subscriber that is most likely a securitythreat.

Detection of a Subscriber that is Over Privileged:

This use case represents when a subscriber 136 has authorizationprivileges beyond those anticipated for the subscriber's 136 class ofAuthenticated Identity Token. For example, the subscriber 136 may haveaccess to Relying Party 140 resources that are inconsistent with thenormal types of access requests made by others with the same jobfunction.

Detection of a Subscriber that is Overtly Changing their Behavior inOrder to Probe for Security Holes and/or Gain Additional Access:

This use case is similar to the Insider Threat Use Case with theexception that the subscriber 136 may be attempting to probe for holesin the Trust Policies. For example, the subscriber 136 may makes subtlechanges to their behavior that does not necessarily representunanticipated behavior at a particular point in time. However, when thisbehavior is examined over an extended period of time, a pattern ofunanticipated behaviors can be discovered that represents subtleattempts to probe for holes in the Trust Policies.

Detection of Trust Policies that are too Restrictive or too Relaxed:

For this use case a subscriber 136 is unintentionally being denied avalid access request or is unintentionally being granted a non-validaccess request for the subscriber's 136 class of Authenticated IdentityToken and Identity Token Authorization Assertions. This use case mayrepresent a problem with the way one or more Trust Policies have beendefined and are being enforced. Additionally or alternatively, this usecase may represent a problem with the way the Authenticated IdentityToken and corresponding Identity Token Authorization Assertions havebeen defined.

Classification of Subscriber Behavior with Respect to the ServicesProvided by the Relying Parties:

For this use case, the intent may include characterizing overallsubscriber 136 population behaviors rather than only characterizing anindividual subscriber's 136 behavior. These more global identityanalytics provide detailed insight into subscriber 136 trends withrespect to web sites, applications, services, and data sources.Additionally, these subscriber 136 patterns provide insight into therelationships between subscriber identity credentials and usage/behaviorpatterns, identity credential data attributes/factors, and accessprivileges.

FIGS. 2-6 show various process data flow diagrams associated with theoperational scenarios provided above. As shown in FIGS. 2-6, data flowsmay be represented by specific labeled arrows between elements of thesystem. As illustrated in each of the data flow diagrams, large amountsof highly distributed information may need to be harvested, collected,exchanged, analyzed, and correlated in order to form a global knowledgebase that captures an identity credential lifecycle.

Referring now to FIG. 2, the process data flow diagram 200 associatedwith a Subscriber 136 registering with the Trust Framework 108 is shownin accordance with embodiments of the present disclosure.

The data flow diagram 200 shows a Trust Framework Subscriber 136 sendingidentity data 216 to the Registration/Provisioning Authority 112 torequest membership. Using the identity data 216, theRegistration/Provisioning Authority 112 makes a request 220 to theIdentity Analytics and Intelligence Engine 104 to verify theSubscriber's 136 Identity Credential Information. In response toreceiving the request 220, the Identity Analytics and IntelligenceEngine 104 queries 224 the Authoritative Identity Data Sources 144having cloud-hosted identity fraud capabilities. In some embodiments,the cloud-hosted identity fraud capabilities may be provisioned by oneor more Cloud Vendor Sources (CVS) 208. Examples of CVS 208 companiesinclude, but are in no way limited to, IDology, Socure, etc. Among otherthings, the query 224 may be made to determine the validity of therequest 220. In one embodiment, the data flow may continue bydetermining whether to complete the registration, for example, wheresufficient identity data exists. Sufficient identity data may be basedon one or more of the identity credential factors previously described.Identity credential factors may include “Something you Know,” “Somethingyou Have,” and/or “Something you Are,” to name a few.

In the event that the registration request is valid and sufficientidentity credential data exists, then the valid verification results228A are returned to the Registration/Provisioning Authority 112.However, in the event that the registration request is not valid andsufficient identity credential data does not exist, then an invalidregistration request may be sent as the verification results 228A. Insome embodiments, the identity data retrieved by the Identity Analyticsand Intelligence Engine 104 may be formatted and returned to theRegistration/Provisioning Authority 112 to provision the Subscriberidentity data in the Physical and Virtual Identity Directories 116. Insome embodiments, the verification results 228B may be sent to theEngine Dashboard 204 for review and/or action. The verification results228B may be sent to the Engine Dashboard 204 in cases where theregistration request is found to be valid or invalid.

Next, the Registration/Provisioning Authority 112 retrieves the requiredidentity credential data 232 for a valid registration request from theauthoritative sources 144. In some embodiments, the Identity Analyticsand Intelligence Engine 104 may retrieve this required identitycredential data 232 as part of providing the verification results 228Aas described above. In any event, the Registration/ProvisioningAuthority 112 then may automatically provision the Subscriber identitycredential data 236 in the Physical and Virtual Identity Directories116. The data flow may end by sending a registration confirmation notice240 to the Subscriber 136.

FIG. 3 describes the process data flow 300 associated with anAdministrator making a data change to one or more of the AuthoritativeIdentity Data Sources that creates the need to re-provision an existingSubscriber 136.

In FIG. 3 a Trust Framework Administrator may make a change 304 to theSubscriber identity credential data stored in the Authoritative IdentityData Sources 144. In response to the change 304, a Subscriber DataChange Event 308 may be sent to the Registration/Provisioning Authority112 to re-verify the Subscriber identity credentials and re-provisionthe Subscriber identity credential data in the Physical and VirtualIdentity Directories 116. In one embodiment, theRegistration/Provisioning Authority 112 makes a request 312 to theIdentity Analytics and Intelligence Engine 104 to re-verify theSubscribers Identity Credential Information. The Identity Analytics andIntelligence Engine 104 may then query 316 the Authoritative IdentityData Sources 144 and interfaces with cloud-hosted identity fraudcapabilities to re-verify the Subscriber identity credential data. Insome embodiments, the cloud-hosted identity fraud capabilities may beprovisioned by one or more Cloud Vendor Sources (CVS) 208. Examples ofCVS 208 companies include, but are in no way limited to, IDology,Socure, etc. If the identity credential data change event is valid andsufficient identity credential data exists, then the valid verificationresults 320A may be returned to the Registration/Provisioning Authority112. Otherwise, an invalid data change event has occurred and is sent asthe verification results 320A. In one embodiment, and as part of thisdata flow step, the identity credential data retrieved by the IdentityAnalytics and Intelligence Engine 104 may be formatted and returned tothe Registration/Provisioning Authority 112 to provision the Subscriberidentity credential data in the Physical and Virtual IdentityDirectories 116.

Regardless of whether the registration event is valid or invalid, theverification results 320B may be sent to the Engine Dashboard 204 forreview and/or action. Next, the Registration/Provisioning Authority 112retrieves the required identity credential data 232 for the identitycredential data change event from the authoritative sources 144. In someembodiments, the Identity Analytics and Intelligence Engine 104 mayretrieve this required identity credential data 232 as part of providingthe verification results 320A as described above. In any event, theRegistration/Provisioning Authority 112 then may automaticallyre-provision the Subscriber identity credential data 236 in the Physicaland Virtual Identity Directories 116.

FIG. 4 describes the process data flows associated with a Subscriber 136making a request to the Trust Framework 108 for an AuthenticatedIdentity Token that will allow access the protected resources of aRelying Party 140.

The data flow diagram 400 shows a Trust Framework Subscriber 136requesting access 404 to a Relying Party 140 via the ISP 120. The ISP120 then makes a request 408 to the Identity Analytics and IntelligenceEngine 108 to analyze the Subscriber's access request. In response, theIdentity Analytics and Intelligence Engine 108 queries 412 theSubscriber Usage Patterns 156 to determine the Subscriber's 136 behaviorpatterns. In some embodiments, the Identity Analytics and IntelligenceEngine 104 may additionally query the Trust Policies and Reaction Rules428 to determine if the Subscriber's access request is within statedTrust Policies. This information may be analyzed by the IdentityAnalytics and Intelligence Engine 104 to verify that the request isvalid.

If the access request is valid, the Identity Analytics and IntelligenceEngine 104 can return the valid access request analysis results 416A tothe ISP 120. Otherwise, an invalid access request has occurred and theinvalid access request analysis results may be sent as the verificationresults 416A. Regardless of whether the access request is determined tobe valid or invalid, the access request analysis results 416B can sentto the Engine Dashboard 204 for review and/or action.

Next, the ISP 120 may retrieve 420 the Subscriber's Identity Token datafrom the Physical and Virtual Identity Directories 116. The ISP thensends the Subscriber 136 an Authenticated Identity Token to access theRelying Party 140.

FIG. 5 describes the process data flows associated with a Subscriber 136requesting access to the protected resources 544 of a Relying Party 140by sending the Relying Party 140 an Authenticated Identity Token and theresulting logging of passing the Identity Token Authorization Assertionsto the Relying Party 140.

The data flow diagram 500 begins when a Trust Framework Subscriber 136requests access to a Relying Party 140 by sending them an AuthenticatedIdentity Token 504. The Relying Party 140 may then send 508 theAuthenticated Identity Token to the Identity Authorization Verificationcapability 124. In response, the Identity Authorization Verificationcapability 124 sends an authorization request 512 to the ISP 120. TheISP 120 can then retrieve 516 the Subscriber's Identity TokenAuthorization Assertions from the Physical and Virtual IdentityDirectories 116. Next, the ISP 120 sends 520 a Log Authorization Requestto the Identity Analytics and Intelligence Engine 104. The ISP 120returns 524 the Identity Token Authorization Assertions to the IdentityAuthorization Verification capability 124. In response, the IdentityAuthorization Verification capability 124 verifies the authorizationassertions and returns 528 them to the Relying Party 140. The RelyingParty 140 then passes the Authenticated and Authorized ServiceInvocation request to the appropriate protected resources 544 forexecution and return of the service response to the Subscriber 136. TheIdentity Analytics and Intelligence Engine 104 may query 536 theSubscriber Usage Patterns 156 to determine the Subscriber's behaviorpatterns and query 536 the Trust Policies and Reaction Rules 428 todetermine if the Subscriber's access request is within stated TrustPolicies. The authorization request notification results may then besent 540 to the Engine Dashboard 204 for review and/or action.

FIG. 6 describes the process data flows associated with continuouslylogging Relying Party 140 accesses on behalf of the Subscriber 136. Thisscenario logs each of the Identity Token Authorization Assertionsrequests as well as logging the Subscribers behavior with respect toeach of their accesses to the Relying Party protected resources 544.

The data flow diagram 600 begins when a Trust Framework Subscriber 136requests access to a Relying Party 140 by sending them an AuthenticatedIdentity Token 504. The Relying Party 140 may then send 508 theAuthenticated Identity Token to the Identity Authorization Verificationcapability 124. In response, the Identity Authorization Verificationcapability 124 sends an authorization request 512 to the ISP 120. TheISP 120 can then retrieve 516 the Subscriber's Identity TokenAuthorization Assertions from the Physical and Virtual IdentityDirectories 116. Next, the ISP 120 sends 520 a Log Authorization Requestto the Identity Analytics and Intelligence Engine 104. The ISP 120returns 524 the Identity Token Authorization Assertions to the IdentityAuthorization Verification capability 124. In response, the IdentityAuthorization Verification capability 124 verifies the authorizationassertions and returns 528 them to the Relying Party 140. The RelyingParty 140 then passes the Authenticated and Authorized ServiceInvocation request to the appropriate protected resources 544 forexecution and return of the service response to the Subscriber 136.

In some embodiments, a continuous monitoring capability is described inthe data flow diagram 600. For instance, the following steps may occurin parallel to perform a continuous monitoring capability. A distributedcollection process may be executed against the Relying Parties ResourceLog Files 548 to continuously collect and record Subscriber behaviorbased on their identity credentials. The Identity Analytics andIntelligence Engine 104 may continuously: query 608 the Subscriber UsagePatterns 156 to determine the Subscriber's behavior patterns, query 608the Trust Policies and Reaction Rules 428 to determine if theSubscriber's access request is within stated Trust Policies, and evenquery 608 the Recorded Identity Behaviors 604 associated with theRelying Party 140 to determine if the Subscriber's authorization requestis consistent with previous requests. A continuous analysis process maybe performed on the query results to update Subscriber Usage Patterns156, Check Subscriber usage against the Trust Policies and ReactionRules 428, and trigger any required threat indicators and/or reactionrules. The Identity Analytics and Intelligence Engine 104 may sendUnanticipated Behavior Detected Notifications to the Engine Dashboard204 for review and/or action. The Identity Analytics and IntelligenceEngine may send routine and recurring Anticipated Behavior Notificationsto the Engine Dashboard 204 for review and/or action.

An embodiment of a method 700 to analyze security and normalize logfiles is shown in FIG. 7. A general order for the steps of the method700 is shown in FIG. 7. Generally, the method 700 starts with a startoperation 704 and ends with an end operation 728. The method 700 caninclude more or fewer steps or can arrange the order of the stepsdifferently than those shown in FIG. 7. The method 700 can be executedas a set of computer-executable instructions executed by a computersystem and encoded or stored on a computer readable medium. Hereinafter,the method 700 shall be explained with reference to the systems,components, modules, software, data structures, user interfaces,databases, etc. described in conjunction with FIGS. 1-6.

The method 700 begins at step 704 and proceeds by receiving log filesfrom one or more sources (step 708). In some embodiments, the log filesmay be provided by one or more security analysis tools and/orcategories. Examples of these security analysis tool categories mayinclude, but are in no way limited to, Network Traffic Inspectors,Identity and Access Management Products, System and/or SecurityIntelligence Products, Platform Analysis Products, and the like. Theservices falling under these categories may be provided by one or morevendors. Although these vendors may provide “point solutions” forspecific types of security problems, these problems may be unrelated toidentity credential misuse. Among other things, the security tools aloneprovided by the vendors do not address the challenges of credentialmisuse nor do they offer rapid detection capabilities. It is an aspectof the present disclosure to continuously monitor the informationprovided under one or more of the security analysis tool categories andintegrate, as well as correlate, the large volumes of data. Additionallyor alternatively, the embodiments disclosed herein provide continuousmonitoring solutions that are able to correlate large amounts of small,distributed pieces of identity credential lifecycle data to discoverhidden patterns and correlations. Additionally or alternatively, theIdentity Analytics and Intelligence Engine 104 may be configured toreceive server and/or application log files in step 708. Some examplesof log files may include, but are not limited to, Log4j, Common EventFormat (CEF), Syslog, and/or other vendor-specific formats.

Next, the method 700 may continue by normalizing the security analysisand log files (step 712). For example, using a Database of ConversionRules, a Log File Normalization component may convert the log file datainto a normalized form. This normalized form can expedite the process ofcreating Resource Description Framework (RDF) triples. In any event, thenormalized log files may be stored to a memory in step 716.

The method 700 proceeds by generating RDF triples from the normalizedlog files (step 720). Among other things, the RDF triples can providesemantic web properties. In some embodiments, RDF triples may berepresented as a triple consisting of <subject, predicate, object>. RDFtriples may be used to make statements about resources, for example, inparticular web resources. The subject may denote the resource; thepredicate may denote traits, or properties, of the resource and can alsoexpress a relationship between the subject and the object. The objectmay denote another resource or a value. In some embodiments, theDatabase of Conversion Rules can be used to transform the contents ofthe normalized log files into RDF triples. The generated RDF triples maybe stored in a graph database in step 724. The method 700 may end atstep 728.

One example log file content to RDF triple conversion rule isillustrated in the following table:

TABLE 5 Corresponding RDF Log File Content Triple Element User Name (ASubscriber) Subject Source IP Address Attribute of Subject Partner IDCode Attribute of Subject Event (Request for Service) PredicateTransaction Request Time Attribute of Predicate Security Token ProtocolAttribute of Predicate Host Server Name Attribute of Predicate ServerRole Attribute of Predicate Target Application URL (Relying Party)Object Time to Process Request Attribute of Object Result Status CodeAttribute of Object Error Code Description Attribute of Object

FIG. 8 shows an operational network 800 ecosystem view of the datainteractions within a trust framework 108 in accordance with embodimentsof the present disclosure. In some embodiments, the Identity Analyticsand Intelligence Engine 104 automated process may be implemented as aset of cloud-hosted, SaaS interfaces. FIG. 8 illustrates how the SaaSinterfaces may be used to automatically collect highly distributedidentity credential lifecycle data. The collected data may then bestored within the graph database of the Identity Analytics andIntelligence Engine 104 of the Identity Analytics Module 808 for furtheranalysis by data analytics and machine learning algorithms. The IdentityAnalytics Module 808 can include one or more of metadata models orcatalogs 128, machine learning algorithms, graph databases, trustpolicies, usage patterns, dashboard and reporting elements, and thelike.

A canonical data model with metadata (e.g., stored in one or more of themetadata catalogs 128 or other memory of the Identity Analytics Module808) has been created. The canonical data model can provide astandardized definition of the nodes and edges contained within thegraph database. The standardized definitions allow for the easy creationof public interfaces that allow for many different types of publishersand consumers to utilize the collected identity lifecycle data. Themetadata provides the semantic definitions of the identity credentiallifecycle data, and the metadata allows for the graph database contentsto be visible, understandable, and accessible for a wide variety ofusers via data publishing and searching techniques.

For example, the metadata can allow for rapid searching and searchresults collection for analysis and correlation by data analytics andmachine learning algorithms. The data analytics and machine learningalgorithms are used to create the subscriber usage and behaviorpatterns. As real-time data flow exchanges are occurring, the IdentityAnalytics and Intelligence Engine 104 of the Identity Analytics Module808 compares the real-time subscriber behavior to their historical usageand behavior patterns to determine if inappropriate, unanticipated,non-compliant, and/or illegal subscriber behavior is occurring. The term“real-time” as used herein may correspond to the time during which aprocess and/or event occurs. In some embodiments, performing an action“in real-time” may include the time during which a process and/or eventoccurs and adding any other time associated with processing, sendingdata, receiving data, and/or translating data required in performing theaction.

FIG. 8 may also be used to illustrate the types of identity credentialdata being exchanged in a Cloud Computing and Internet of Thingsenvironment. For example, information provided by Subscribers 136 to theNetwork Topology 800 can include one or more of registration requests,authenticated token requests, relying party requests, and the like. Thisinformation illustrates the types of data flow information the IdentityAnalytics and Intelligence Engine 104 can automatically and continuouslycollect from all elements of the Trust Framework 108.

Each element in the network topology 800 may include various SaaSinterfaces that provide for the exchange of information between theelements across a network 804. In accordance with at least someembodiments of the present disclosure, the network 804 may comprise anytype of known communication medium or collection of communication mediaand may use any type of protocols to transport messages betweenendpoints. The network 804 may include wired and/or wirelesscommunication technologies. The Internet is an example of the network804 that constitutes an Internet Protocol (IP) network consisting ofmany computers, computing networks, and other communication deviceslocated all over the world, which are connected through many telephonesystems and other means. Other examples of the network 804 include,without limitation, a standard Plain Old Telephone System (POTS), anIntegrated Services Digital Network (ISDN), the Public SwitchedTelephone Network (PSTN), a Local Area Network (LAN), a Wide AreaNetwork (WAN), a Voice over Internet Protocol (VoIP) network, a cellularnetwork, and any other type of packet-switched or circuit-switchednetwork known in the art. In addition, it can be appreciated that thenetwork 804 need not be limited to any one network type, and instead maybe comprised of a number of different networks and/or network types.Moreover, the network 804 may comprise a number of differentcommunication media such as coaxial cable, copper cable/wire,fiber-optic cable, antennas for transmitting/receiving wirelessmessages, and combinations thereof. The network 804 may provide avariety of services, such as communication services, data exchange,notification services, and the like between the various components ofthe network topology 800.

The Relying Parties 140 element may include one or more SaaS interfacesand log file formats. The log files may be contained in a number ofSecurity Information and Event Management (SIEM) formats 820A-N. TheRelying Parties 140 may take receipt of Authenticated Tokens andAssertions, request to verify authorizations, store SIEM and/or otherlog files, combinations thereof, and/or the like.

In addition to including the SaaS interfaces, the Identity as a Service(IDaaS) Providers 812 component may include one or more of AuthoritativeSources for Identity Attributes 144, Physical and Virtual IdentityDirectories 116, and ISP 120. The IDaaS Providers 812 can store and/ormanage identity attributes, registration keys, tokens and assertions,access request logs, etc.

FIG. 9 shows a block diagram of a graph database design model 900 inaccordance with embodiments of the present disclosure. In someembodiments, the Identity Analytics and Intelligence Engine 104 canprovide a decentralized platform for distributed identity credentialdata in a manner that allows it to be treated as a knowledge base. Thisplatform is a perfect match for the concepts and technologies associatedwith the Semantic Web. For instance, Semantic Web concepts andtechnologies were created to address how large amounts of small piecesof information distributed over a large number of internet-based sitescan be analyzed and correlated to create a higher level of knowledge andinsight. As described herein, the Identity Analytics and IntelligenceEngine 104 is able to deal with the existence of a large number ofsmall, distributed pieces of identity credential data that are notindependent of each other. Thus, these small pieces of distributedidentity credential data need to be related to each other to form a bigpicture view of the distributed identity credential data so that it canbe treated as a global knowledge base for inferring cyber threat/attackinformation and activities. The global knowledge base is used by a setof automated Identity Analytics and Intelligence Engine 104 mechanismsfor detecting, reporting, cueing, analyzing, correlating, and takingpreventative actions to protect the network, trusted resources, andassociated data.

The Identity Analytics and Intelligence Engine 104 may use a graph datastructure to capture the distributed identity credential data and createa knowledge base. The RDF can be used to specify the canonical datamodel for the distributed identity credential data represented as graphnodes and edges. The graph nodes capture the small, seeminglyindependent, pieces of distributed identity credential data. Whereas,the graph edges represent relationships between the nodes, and the edgesare the basis for creating knowledge connections. A graph database maybe used to allow the distributed identity data to be collected, stored,queried, exchanged, and maintained as RDF triples. Additionally,identity credential related metadata is used to index the node and edgeproperties (or attributes) to allow for the fast query and retrieval ofdata sets to be used as input for data analytics and machine learningalgorithms. In essence, the identity credential metadata provides themechanism for management policies that make the graph database contentsvisible, accessible, and understandable for consumption by both humansand automated tools. A specific example of automated tools used by theIdentity Analytics and Intelligence Engine 104 are machine-learningalgorithms applied to the graph database information to discover thehidden patterns, unknown correlations, and other useful identity relatedknowledge.

As shown in FIG. 9 a detailed set of RDF triples that are capturedwithin the Identity Analytics and Intelligence Engine graph database areillustrated. An RDF triple takes the form of a <subject, predicate,object>, and may be used to make statements about resources (inparticular web resources). The subject denotes the resource; thepredicate denotes traits (or properties) of the resource; the alsopredicate expresses a relationship between the subject and the object;and the object denotes another resource or a value. Some examples fromFIG. 9 are the RDF triples defined by <Identity Credentials, Map-To,Subscriber> (shown as node “IC” 908 mapping to node “S” 136),<Subscriber, Requests-Services-From, Relying Party>, (shown as node “S”136 requesting services from node “RP” 140) and <Relying Party,Produces, Recorded Behaviors> (shown as node “RP” 140 produces node “RB”604). The RDF triples can be used as the basis for storing and composingthe identity credential lifecycle data so that it can be easily queried.The RDF triples may be generated by the process described in conjunctionwith FIG. 10. Other nodes illustrated in FIG. 9 correspond to the ISP120, the Protected System Resource (PSR) 544, the Usage Pattern (UP)156, the Identity Token (IDT) 912, the Authorization Assertions (AA)916, the Registration Key (RK) 920, the Authoritative Source (AS) 924,the Registration/Provisioning Authority (RPA) 112, and the Trust Policy(TP) 928, to name a few.

A common way to determine the consistency and completeness of RDFtriples within a graph database model is to evaluate whether or not aset of example queries can be satisfied. Examples of identity credentiallifecycle related queries that can be satisfied by the IdentityAnalytics and Intelligence Engine 104 can include, but are in no waylimited to, the following: 1) Simple Queries—WhatRegistration/Provisioning Authority did Subscriber “X” Register With?What Identity Credentials Map-To Subscriber X? What Identity CredentialsAllow Access to Relying Party “X”? What are Subscriber “X” IdentityCredentials Composed of? What Identity Service Provider ManagesSubscriber “X” Identity Credentials? What Trust Policies does Subscriber“X” Comply With? What Usage Pattern has Subscriber “X” Generated? WhatRelying Parties has Subscriber “X” Requested Services From? WhatIdentity Service Provider does Relying Party “X” Verify With? WhatProtected System Resources are Hosted By Relying Party “X”? WhatRecorded Behaviors are Produced By Protected System Resource “X”? and 2)Complex Queries—What Authoritative Sources were Accessed By theRegistration/Provisions Authority to Provision Subscriber “X”? WhatProtected System Resources has Subscriber “X” Requested Services From?What Recorded Behaviors Produced by Identity Credential “X” Map-ToSubscriber “Y”? What Protected System Resources are Aggregated IntoUsage Pattern “X”? What Subscribers Map-To Authorization Assertion “X”?These simple and complex queries represent identity credential lifecycledata related to the types of points presented above. Specifically,relating identity credential lifecycle data to subscriber usage andbehavior patterns.

The canonical data model for the identity credential lifecycle data is akey, unique feature of the Identity Analytics and Intelligence Engine104. The canonical data model may be specified using JavaScript ObjectNotation-Linked Data (JSON-LD). JSON-LD may be used to provide aJava-based specification of the RDF triples using Java/JavaScriptobjects rather than other representations such as eXtended MarkupLanguage (XML). JSON-LD is much more amenable to the development ofJava-based algorithms and other automated capabilities, and JSON-LD mayprovide a more human-readable definition of the RDF triples. Both ofthese aspects allow the Identity Analytics and Intelligence Engine 104to leverage a large body of open source, Java/JavaScript code forperforming graph database manipulations and traversals, data analytics,and machine learning.

The canonical data model we have developed provides solutions to somevery difficult questions regarding how to best create an automatedprocess that collects and analyzes large amounts of highly distributedidentity credential lifecycle information contained on the internet.Specifically, it allows the Identity Analytics and Intelligence Engineto create a set of distributed graph databases where each database canbe configured to 1) reduce the amount of network traffic required totransfer identity credential lifecycle data and 2) exploit parallelprocessing capabilities for computational efficiency. The IdentityAnalytics and Intelligence Engine 104 can use the Apache SoftwareFoundation capability to manage the set of distributed databases.Specifically, Storm may provide a Map-Reduce Engine that is aprogramming model for large-scale, distributed data processing. The Mappart of the Storm Map-Reduce Engine is used to perform filtering andsorting to assist with the creation of data sets that contain theresults of a query to the distributed graph databases. The Reduce partof the Storm Map-Reduce Engine is used to apply summarizing operationson the filtered, distributed data sets. For example, the Reduce part isused to apply machine learning algorithms that create usage and behaviorpatterns for a specified identity credential based on the filtered datacreated by the Map part.

One or more machine learning algorithms, as disclosed herein, may beapplied to the data contained in the graph database. Examples of machinelearning algorithms may include, but are in no way limited to, DecisionTree Learning, Inductive Logic Programming, Clustering, and BayesianNetworks to name a few. Each of these algorithms are further describedbelow:

Decision Tree Learning:

Decision trees may be used as a predicative model to map observed usagepatterns to conclusions about whether or not the observed usage patternsare indicative of cyber threat behaviors. Decision tree machine learningalgorithms can be used within the Identity Analytics and IntelligenceEngine 104 when anticipated usage patterns are well known and easy todescribe. That is, a precise role has been defined for an identitycredential, and this role can be used to define expected usage patterns.

Inductive Logic Programming:

Inductive Logic Programming may be used to analyze combinations ofsecurity policy and security token assertions for toxic combinations.That is, an individual security policy or security token assertion canbe well formed and allow for precise usage behaviors. However, when twoor more of these security policies and/or security token assertions arecombined (or aggregated) they may no longer be well-formed andunanticipated usage behaviors can occur. Inductive Logic Programming maybe used within the Identity Analytics and Intelligence Engine 104 toanalyze security policies and security token assertions for toxiccombinations that allow unanticipated usage behaviors.

Clustering:

Clustering algorithms may be used to cluster observed usage patternsinto subsets. Observed usage patterns in the same cluster representsimilar behavior patterns while observed usage patterns in differentclusters represent dissimilar behavior. Cluster algorithms can be usedwithin the Identity Analytics and Intelligence Engine 104 to quicklylearn and associate usage patterns with identity credential roles andtoken assertions. Additionally, clustering algorithms can be used torapidly detect when a divergence is occurring from a historical usagepatterns that indicates identity credential misuse is occurring.

Bayesian Networks:

Bayesian Networks may be used to represent a probabilistic relationship(or prediction) between usage patterns and potential cyber threatbehaviors that indicate identity credential misuse. Bayesian Networkscan be used within the Identity Analytics and Intelligence Engine 104 asan accurate predictor of identity credential misuse.

The architecture and design of the Identity Analytics and IntelligenceEngine is built on a unique composition of open source tools and opensource standards. These tools can include: JavaScript ObjectNotation-Linked Data (JSON-LD) to specify the graph-based canonical datamodel and metadata; the graph database (e.g., AllegroGraph, etc.);Apache SOLR/Lucene to provide fast indexing and searching based on theidentity credential lifecycle metadata; Apache Mahout for theapplication of a wide variety of machine learning algorithms; ApacheStorm to provide fast, distributed collection and dissemination of thecloud-hosted identity credential lifecycle data; and the use of existingidentity credential and recorded system behavior information containedin Security Information and Event Management (SIEM) and other types ofserver/system log files.

The analysis, correlation, reporting, and cueing components built on theopen source tools provides the automated, knowledge-based capability tomake identity credential lifecycle and other IT security relateddecisions. Additionally the tools are used to provide robust situationalawareness and assessment with respect to subscriber behaviors within oneor more Trust Frameworks. Open architecture and interface standards areused to create a plug-and-play capability that is hosted as an SaaScapability. By using a SaaS-based deployment capability, the IdentityAnalytics and Intelligence Engine has a neutral computing platform andis minimally invasive from the perspective of the businesses subscribingto the SaaS-based capability. Additionally, the use of open sourceproducts provides a large community of contributors from which new dataanalytics and machine learning algorithms and components from relatedefforts in semantic web, graph databases, data analytics, and machinelearning can be quickly incorporated.

An embodiment of a method 1000 to determine and analyze subscriberbehavior patterns is shown in FIG. 10. A general order for the steps ofthe method 1000 is shown in FIG. 10. Generally, the method 1000 startswith a start operation 1004 and ends with an end operation 1040. Themethod 1000 can include more or fewer steps or can arrange the order ofthe steps differently than those shown in FIG. 10. The method 1000 canbe executed as a set of computer-executable instructions executed by acomputer system and encoded or stored on a computer readable medium.Hereinafter, the method 1000 shall be explained with reference to thesystems, components, modules, software, data structures, userinterfaces, databases, etc. described in conjunction with FIGS. 1-9.

The method 1000 begins at step 1004 and proceeds by detecting theidentity credential of a user or Subscriber 136 (step 1008). TheIdentity Analytics and Intelligence Engine 104 may then establish abaseline, or basis, use behavior for the Subscriber 136 and the detectedidentity credential 1012. The use behavior may correspond to one or moreactions or inactions of the Subscriber 136 that are made over time. Inany event, this baseline use behavior may be stored in a memoryassociated with the Identity Analytics and Intelligence Engine 104 (step1016).

Next, the method 1000 may continue by monitoring the use behavior of theidentity credential (step 1020). Monitoring use behavior may includecollecting data corresponding to behavior patterns as described herein.For example, the Identity Analytics and Intelligence Engine 104 maymonitor for event information related to one or more actions orinactions of a user with an identity credential. The method 1000 maythen determine whether there is any deviation between the monitored usebehavior and the baseline use behavior (step 1024). If no deviation isdetected or determined, the method 1000 may return to step 1020 tocontinuously monitor the use behavior associated with the identitycredential. However, if a deviation is determined, the IdentityAnalytics and Intelligence Engine 104 may determine whether thedeviation is within an acceptable threshold or limits (step 1028). Thisdetermination may include referring to rules and/or trust policies inmemory, where the threshold or limits are stored.

In the event that a deviation in use behavior is determined to beacceptable, or fall within acceptable limits, the Identity Analytics andIntelligence Engine 104 may determine to modify the baseline usebehavior stored in memory (step 1032). This modification may includeapplying one or more machine learning algorithms to the data collectedand/or stored in the graph database, as described herein. Modifying thebaseline use behavior may include changing the baseline use behaviorinformation stored in the memory associated with the Identity Analyticsand Intelligence Engine 104. When a deviation in use behavior isdetermined to fall outside of the acceptable limits or threshold (e.g.,the deviation is unacceptable, etc.), the method 1000 may proceed byreporting identity credential misuse (step 1036). In some embodiments,reporting misuse may include providing a notification to at least one ofa Relying Party 140, a Subscriber 136, an administrator, monitor, orother entity.

In one embodiment, the notification may be automatically presented, orrendered, to a display associated with a communication device (e.g., aphone, tablet, computer, mobile computer, etc.). For instance, thenotification may be sent as a text message or prompt configured to alerta user of the identity credential misuse. Continuing this example, auser may interact with the text message or prompt to take further actionregarding the misuse. This interaction may include confirming that thereported misuse is true, providing a response that the reported misuseis a false report, updating access policies, and/or restrictingparticular access by identity credential. Although the method 1000 mayend at step 1040, it should be appreciated that the use behaviorassociated with the misuse may be continually monitored by the IdentityAnalytics and Intelligence Engine 104.

It is an aspect of the present disclosure that reporting identitycredential misuse may take a variety of forms. For example, reportingidentity credential misuse may include rendering a new challengequestion or verification element to a communication device (e.g., to thedisplay of a communication device, in the form of a text message, as aprompt, etc.) associated with a credential user. The new challengequestion may be created by one or more elements of the Trust Framework108. For instance, rather than utilizing a stored challenge question(e.g., previously created and/or used by a user) the one or moreelements of the Trust Framework 108 may review data in the TrustFramework 108 for generating a new challenge question. In someembodiments, this new challenge question may be based on usage, or use,patterns, stored data, and/or the like. As can be appreciated, a newchallenge question having a unique answer that may only be known by theTrust Framework 108 and the user may serve to thwart identity theft viasocial engineering and/or other data gathering. Among other things, achallenge question that is not created by the user, or previously used,could not be easily retrieved by an identity thief or other entityemploying a data gathering tool.

Additionally or alternatively, reporting may include automaticallyrevoking authorization of identity credentials until further review.This revocation may include shutting down a resource, isolating aresource, and/or restricting access to or from a resource.

In some embodiments, the layered, Component Architecture for theIdentity Analytics and Intelligence Engine 104 may be described asfollows. Each layer may be separated by technology independent, openstandards compliant interfaces. This separation can provide a set ofabstraction layers that enable all components to be loosely coupled andthereby, easily replaceable as new technologies and other componentsbecome available. The architecture may comprise User Dashboard andReporting, Identity Analytics and Intelligence Engine Services, OpenSource Product Services, and/or Data Services.

User Dashboard and Reporting:

This layer is a robust user interface that can be built using web 2.0concepts and technologies. It may be used to display various identitycredential lifecycle data to include reporting, cues, alerts, reports,notifications and other types of information as described in the dataflow description tables provided above. The dashboard may be monitoredautomatically, semi-automatically, or manually depending on theconfiguration. In some embodiments, the information and/or reportingprovided to the dashboard may be accessed by one or more entities,including but not limited to, an administrator, a monitoring service, atrust framework host, a relying party, a user, and/or a subscriber. Insome embodiments, the relying party or any other entity having access tothe dashboard and reporting may be subject to certain restrictions as towhat data is accessible and/or reviewable.

Identity Analytics and Intelligence Engine Services:

This layer implements the top-level capabilities and services thatexecute the continuous monitoring and user behavior characterizationfeatures. In general, these capabilities and services can be deployedeither as SaaS interfaces or Secure API's.

Open Source Product Services:

This layer provides the abstract interfaces to the open source productssuch as the products provided by the Apache Software Foundation. Theseproducts can provide the indexing and searching (e.g., ApacheSolr/Lucene), machine learning (Apache Mahout), and large-scaledistributed data processing capabilities (Apache Storm).

Data Services:

This layer provides the abstract interfaces to the large amounts of datacollected, analyzed, and correlated by the Identity Analytics andIntelligence Engine 104. Beneath this layer are the physical storagecapabilities such as the AllegroGraph graph database and other types ofNOSQL and SQL based databases.

The data structures maintained by the Data Services is a unique featureof the Identity Analytics and Intelligence Engine 104. These datastructures can be used to: 1) represent training sets for the machinelearning algorithms to learn anticipated subscriber behaviors, 2)capture subscriber usage and behavior patterns based on identitycredential lifecycle data, and 3) provide the mechanisms to define andimplement formal metrics that measure the variances/deviations betweenanticipated and unanticipated behaviors. The latter is of particularimportance because it serves to minimize a potentially large number of“false positives” when formal metrics are not implemented and tied tothe key data structures.

The canonical data model, data structures, and component architecture ofthe Identity Analytics and Intelligence Engine 104 can implement a moregeneric data/information lifecycle model. The current focus is on theidentity credential lifecycle model along with the mechanisms to rapidlycollect, analyze, correlate, and report on identity lifecycle knowledgeobtained via our semantic web, graph database, data analytics, andmachine learning framework. Other types of information lifecycles canalso be modeled and processed by the framework.

For example, the data associated with a command and control (C2) systemcan be modeled. Each user of the command and control system would haveexpected/anticipated C2-related behaviors based on theinformation/knowledge contained on large-scale distributed networks.Suppose unanticipated behaviors were detected and reported by thelifecycle-modeling framework. Additionally, suppose the unanticipatedbehaviors required different IT subscriber authentication andauthorization properties for their identity credential. By composing theidentity credential lifecycle data with the C2 lifecycle data, it wouldbe possible to define and implement the concept of “AdaptiveAuthentication and Access Control.” That is, unanticipated behaviorsdetected and reported in the C2 lifecycle data are used to enable andauthorize additional controlled behaviors in the identity credentiallifecycle that enables the subscriber(s) to perform processing functionsthey wouldn't normally be authorized to perform. The concept of AdaptiveAuthentication and Access Control is being actively researched, but isunaware of any research that is applying data/information lifecyclemodeling to support this type of capability.

The Identity Analytics and Intelligence Engine 104 can provide asolution to a rapidly escalating need for an automated process thatconnects together, correlates, and continuously monitors and manages anexponentially increasing number of highly distributed identitycredentials across a large number of organizations. The IdentityAnalytics and Intelligence Engine 104 harvests large amounts ofdistributed identity credential lifecycle data from public/privateclouds as well as the emerging Internet of Things. The IdentityAnalytics and Intelligence Engine 104 applies Semantic Web concepts andtechnologies to create a knowledge base of identity credential lifecycledata that can be rapidly analyzed to detect, prevent, and respond todata loss events, fraudulent transactions, and suspicious/unanticipatedIT User behaviors based on their identity credentials.

Overall, the Identity Analytics and Intelligence Engine 104 cansignificantly shorten the detection, proactive prevention, and reactiontimes for identity credential misuse and related cyber threats/attacks.The Identity Analytic and Intelligence Engine 104 unlocks the identitycredential lifecycle data from multiple distributed sources, links itwith data loss prevention capabilities, and places the identitycredential lifecycle data into a semantic web knowledge base. Theknowledge base is leveraged as the mechanism to design and implementseveral innovative detection, prevention, and defensive capabilitiesthat proactively instead of reactively address cyber threats/attacks.

Among other things, the Identity Analytics and Intelligence Engine 104may be configured to: Continuously monitor usage behavior to quicklydetect, proactively prevent, and respond to outlier/unanticipated userbehaviors; Quantitatively measure the variance between normal usage andunanticipated usage behaviors in a manner that prevents an attack beforeit begins by determining what defensive measures to apply in anautomated manner; Apply a tiered approach to allow multi-level,preventative analysis of usage patterns and behaviors; Provide a basisfor automated reviews of user accounts for reasonability by usingbehavioral analysis to identify and protect againstoutlier/unanticipated activities; Assist with the deployment andmanagement of sophisticated multi-factor access approaches; and/orProvide detailed insight into user access trends for websites/applications, web services, and data services that provide astrong connection between user identity credential policies and theiractual usage patterns, identity credential data attributes, and accessprivileges.

The accompanying drawings are incorporated into and form a part of thespecification to illustrate several examples of the present disclosure.These drawings, together with the description, explain the principles ofthe disclosure. The drawings simply illustrate preferred and alternativeexamples of how the disclosure can be made and used and are not to beconstrued as limiting the disclosure to only the illustrated anddescribed examples. Further features and advantages will become apparentfrom the following, more detailed, description of the various aspects,embodiments, and configurations of the disclosure, as illustrated by thedrawings referenced below.

The exemplary systems and methods of this disclosure have been describedin relation to identity analysis systems and methods. However, to avoidunnecessarily obscuring the present disclosure, the precedingdescription omits a number of known structures and devices. Thisomission is not to be construed as a limitation of the scopes of theclaims. Specific details are set forth to provide an understanding ofthe present disclosure. It should however be appreciated that thepresent disclosure may be practiced in a variety of ways beyond thespecific detail set forth herein.

Furthermore, while the exemplary aspects, embodiments, options, and/orconfigurations illustrated herein show the various components of thesystem collocated, certain components of the system can be locatedremotely, at distant portions of a distributed network, such as a LANand/or the Internet, or within a dedicated system. Thus, it should beappreciated, that the components of the system can be combined in to oneor more devices, such as a Personal Computer (PC), laptop, netbook,smart phone, Personal Digital Assistant (PDA), tablet, etc., orcollocated on a particular node of a distributed network, such as ananalog and/or digital telecommunications network, a packet-switchnetwork, or a circuit-switched network. It will be appreciated from thepreceding description, and for reasons of computational efficiency, thatthe components of the system can be arranged at any location within adistributed network of components without affecting the operation of thesystem. For example, the various components can be located in a switchsuch as a PBX and media server, gateway, in one or more communicationsdevices, at one or more users' premises, or some combination thereof.Similarly, one or more functional portions of the system could bedistributed between a telecommunications device(s) and an associatedcomputing device.

Furthermore, it should be appreciated that the various links connectingthe elements can be wired or wireless links, or any combination thereof,or any other known or later developed element(s) that is capable ofsupplying and/or communicating data to and from the connected elements.These wired or wireless links can also be secure links and may becapable of communicating encrypted information. Transmission media usedas links, for example, can be any suitable carrier for electricalsignals, including coaxial cables, copper wire and fiber optics, and maytake the form of acoustic or light waves, such as those generated duringradio-wave and infra-red data communications.

Also, while the flowcharts have been discussed and illustrated inrelation to a particular sequence of events, it should be appreciatedthat changes, additions, and omissions to this sequence can occurwithout materially affecting the operation of the disclosed embodiments,configuration, and aspects.

A number of variations and modifications of the disclosure can be used.It would be possible to provide for some features of the disclosurewithout providing others.

Optionally, the systems and methods of this disclosure can beimplemented in conjunction with a special purpose computer, a programmedmicroprocessor or microcontroller and peripheral integrated circuitelement(s), an ASIC or other integrated circuit, a digital signalprocessor, a hard-wired electronic or logic circuit such as discreteelement circuit, a programmable logic device or gate array such as PLD,PLA, FPGA, PAL, special purpose computer, any comparable means, or thelike. In general, any device(s) or means capable of implementing themethodology illustrated herein can be used to implement the variousaspects of this disclosure. Exemplary hardware that can be used for thedisclosed embodiments, configurations and aspects includes computers,handheld devices, telephones (e.g., cellular, Internet enabled, digital,analog, hybrids, and others), and other hardware known in the art. Someof these devices include processors (e.g., a single or multiplemicroprocessors), memory, nonvolatile storage, input devices, and outputdevices. Furthermore, alternative software implementations including,but not limited to, distributed processing or component/objectdistributed processing, parallel processing, or virtual machineprocessing can also be constructed to implement the methods describedherein.

In yet another embodiment, the disclosed methods may be readilyimplemented in conjunction with software using object or object-orientedsoftware development environments that provide portable source code thatcan be used on a variety of computer or workstation platforms.Alternatively, the disclosed system may be implemented partially orfully in hardware using standard logic circuits or VLSI design. Whethersoftware or hardware is used to implement the systems in accordance withthis disclosure is dependent on the speed and/or efficiency requirementsof the system, the particular function, and the particular software orhardware systems or microprocessor or microcomputer systems beingutilized.

In yet another embodiment, the disclosed methods may be partiallyimplemented in software that can be stored on a storage medium, executedon programmed general-purpose computer with the cooperation of acontroller and memory, a special purpose computer, a microprocessor, orthe like. In these instances, the systems and methods of this disclosurecan be implemented as program embedded on personal computer such as anapplet, JAVA® or CGI script, as a resource residing on a server orcomputer workstation, as a routine embedded in a dedicated measurementsystem, system component, or the like. The system can also beimplemented by physically incorporating the system and/or method into asoftware and/or hardware system.

Although the present disclosure describes components and functionsimplemented in the aspects, embodiments, and/or configurations withreference to particular standards and protocols, the aspects,embodiments, and/or configurations are not limited to such standards andprotocols. Other similar standards and protocols not mentioned hereinare in existence and are considered to be included in the presentdisclosure. Moreover, the standards and protocols mentioned herein andother similar standards and protocols not mentioned herein areperiodically superseded by faster or more effective equivalents havingessentially the same functions. Such replacement standards and protocolshaving the same functions are considered equivalents included in thepresent disclosure.

The present disclosure, in various aspects, embodiments, and/orconfigurations, includes components, methods, processes, systems and/orapparatus substantially as depicted and described herein, includingvarious aspects, embodiments, configurations embodiments,subcombinations, and/or subsets thereof. Those of skill in the art willunderstand how to make and use the disclosed aspects, embodiments,and/or configurations after understanding the present disclosure. Thepresent disclosure, in various aspects, embodiments, and/orconfigurations, includes providing devices and processes in the absenceof items not depicted and/or described herein or in various aspects,embodiments, and/or configurations hereof, including in the absence ofsuch items as may have been used in previous devices or processes, e.g.,for improving performance, achieving ease and/or reducing cost ofimplementation.

The foregoing discussion has been presented for purposes of illustrationand description. The foregoing is not intended to limit the disclosureto the form or forms disclosed herein. In the foregoing DetailedDescription for example, various features of the disclosure are groupedtogether in one or more aspects, embodiments, and/or configurations forthe purpose of streamlining the disclosure. The features of the aspects,embodiments, and/or configurations of the disclosure may be combined inalternate aspects, embodiments, and/or configurations other than thosediscussed above. This method of disclosure is not to be interpreted asreflecting an intention that the claims require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive aspects lie in less than all features of a singleforegoing disclosed aspect, embodiment, and/or configuration. Thus, thefollowing claims are hereby incorporated into this Detailed Description,with each claim standing on its own as a separate preferred embodimentof the disclosure.

Moreover, though the description has included description of one or moreaspects, embodiments, and/or configurations and certain variations andmodifications, other variations, combinations, and modifications arewithin the scope of the disclosure, e.g., as may be within the skill andknowledge of those in the art, after understanding the presentdisclosure. It is intended to obtain rights which include alternativeaspects, embodiments, and/or configurations to the extent permitted,including alternate, interchangeable and/or equivalent structures,functions, ranges or steps to those claimed, whether or not suchalternate, interchangeable and/or equivalent structures, functions,ranges or steps are disclosed herein, and without intending to publiclydedicate any patentable subject matter.

What is claimed is:
 1. A method, comprising: collecting informationassociated with an identity credential associated with a user; andcreating two or more distributed graph databases, wherein each graphdatabase is configured to store identity credential lifecycle dataassociated with the identity credential.
 2. The method of claim 1,further comprising: receiving a query associated with the identitycredential lifecycle data of the identity credential; arranging, inresponse to receiving the query, the identity credential lifecycle datain the two or more distributed graph databases for the identitycredential into at least one data set having user behavior information;and summarizing the user behavior information of the at least one dataset.
 3. The method of claim 2, wherein summarizing the user behaviorinformation of the at least one data set further comprises: applying atleast one machine learning algorithm to the user behavior information ofthe at least one data set; and creating, in response to applying the atleast one machine learning algorithm, a use pattern for the identitycredential.
 4. The method of 3, further comprising: creating, inresponse to applying the at least one machine learning algorithm, abehavior pattern for the identity credential.
 5. The method of claim 4,further comprising: storing the use and behavior pattern for theidentity credential in a memory associated with the identity credential.6. The method of claim 5, further comprising: receiving a subsequentquery associated with the identity credential lifecycle data of theidentity credential; arranging, in response to receiving the subsequentquery, the identity credential lifecycle data in the two or moredistributed graph databases for the identity credential into at leastanother data set having user behavior information; applying at least onemachine learning algorithm to the user behavior information of the atleast another data set; creating, in response to applying the at leastone machine learning algorithm, a subsequent use and behavior patternfor the identity credential; and storing the use and behavior patternfor the identity credential in a memory associated with the identitycredential.
 7. The method of claim 2, wherein arranging the identitycredential lifecycle data in the two or more distributed graphdatabases, further comprises: filtering the user behavior information inthe two or more distributed graph databases for the identity credential.8. The method of claim 2, wherein arranging the identity credentiallifecycle data in the two or more distributed graph databases, furthercomprises: sorting the user behavior information in the two or moredistributed graph databases for the identity credential.
 9. A method,comprising: collecting identity lifecycle data associated with at leastone identity credential, wherein the identity lifecycle data includes adefinition of at least one use behavior associated with the at least oneidentity credential; determining an anticipated use behavior based onthe collected identity lifecycle data; and determining a variationbetween the anticipated use behavior and a detected unanticipated usebehavior, wherein the detected unanticipated use behavior includes a usebehavior of the identity lifecycle data that is outside a threshold ofthe anticipated use behavior.
 10. The method of claim 9, wherein thedetected unanticipated use behavior includes at least one of a differentsubscriber authentication and different authorization property for theat least one identity credential than a subscriber authentication andauthorization property associated with the anticipated use behavior. 11.The method of claim 10, wherein the detected unanticipated use behavioris used to at least one of enable and authorize additional controlledbehaviors in the identity credential lifecycle data, wherein theadditional controlled behaviors include a processing functionunavailable to the anticipated use behavior.
 12. A trust frameworksituated between a subscriber having an identity credential and arelying party that provides one or more computing resources to thesubscriber based on identity authorization verifications received fromthe trust framework, the trust framework comprising: an identity andintelligence engine that automatically performs the following: (i)maintains a canonical data model for identity credential lifecycle datarelated to the subscriber; (ii) receives event information related to atleast one of actions and inactions of the subscriber and catalogs theevent information; (iii) compares the received event information withthe canonical data model to determine whether or not the subscriber isacting in conformance with the canonical data model; and (iv) in theevent that the subscriber is determined to be acting out of conformancewith the canonical data model, notifies the relying party therebyenabling the relying party to deny or restrict the subscriber's accessto the one or more computing resources.
 13. The trust framework of claim12, wherein the canonical data model is maintained with informationobtained from a plurality of different data sources.
 14. The trustframework of claim 12, wherein the identity and intelligence enginefurther creates a set of distributed graph databases that represent thecanonical data model.
 15. The trust framework of claim 12, wherein apredetermined deviation between the at least one of actions andinactions and the canonical data model is provided to allow thesubscriber to still be in conformance with the canonical data model evenwhen the at least one of actions and inactions to not exactly match thecanonical data model.
 16. The trust framework of claim 12, wherein theidentity and intelligence engine continuously and automatically updatesthe canonical data model with the at least one of actions and inactionswhen the subscriber is determined to be in conformance with thecanonical data model.
 17. The trust framework of claim 12, wherein theidentity credential lifecycle data includes data related to thecreation, ownership, data update, usage, and patterns of behaviorsassociated with the identity credential.
 18. The trust framework ofclaim 12, wherein the received event information is compared inreal-time.
 19. The trust framework of claim 12, wherein notifying therelying party includes rendering an alert image to a computer displayoperated by the relying party.
 20. The trust framework of claim 14,wherein the identity and intelligence engine automatically analyzes thecanonical data in the graph databases using one or more machine learningalgorithm.